-
-
Notifications
You must be signed in to change notification settings - Fork 823
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dev/core#5603 Support multi-record CustomGroups for Events using Afform tab display #31606
base: master
Are you sure you want to change the base?
Conversation
🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷 Introduction for new contributors...
Quick links for reviewers...
|
@ufundo is the switch from contact_id to entity_id going to affect existing user-created afforms? |
It shouldn't do. I passed entity_id and contact_id in the assign here https://github.com/civicrm/civicrm-core/pull/31606/files#r1887316810 , so either should work (and the other will be ignored if not used). I r-ran as follows:
|
Ok, and what about editing the afform in the GUI. Will the gui have lost track of that reference now that the name changed? |
b818207
to
1bac07c
Compare
Good question. I did look at that briefly and I don't really understand how it works. GUI seems to recognise Though I don't quite know how it does that? (Note: the GUI never likes that |
Noticed an issue with the View links for the individual Custom records -- these are still using a QuickForm that is hard-coded for contact |
Seems fine to me :) |
7092ee0
to
5ec170a
Compare
Rolled back the test changes for blocks as well. Fixed the style, and the other failures looked like flakes, so hoping this will pass. |
The other thing I don't like with the view forms: it's only the DisplayOnly meta at the field level that is stopping you from editing data. It feels like it should be a control at the form level. It would be nice to have an afform mode that is like "this form can prefill data, but not submit". Then you could re-use the Update form (and the afblock), but with that "read-only" toggled. I'd thought of something like that before on the front-end could be neat. User could load the form as read-only, and all the fields are disabled; then (if allowed for that form) they toggle to edit mode, without having to refetch all the data. I guess it would be a bit closer in UX to quickform blocks on the contact summary. That's a chunk more work though, so maybe the approach here is good enough for now? |
@ufundo still looking at a failure in testAfformContactSummaryBlock |
@ufundo I agree that the ability to toggle 'readonly' at the form level would be a great feature! Not a blocker to this PR but a very good idea. |
5ec170a
to
7d51ae3
Compare
retest this please |
The remaining test fail seems to be common across all open PRs at the moment => think unrelated |
@@ -0,0 +1,2 @@ | |||
{assign 'options' ['entity_id' => $eventId]} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is Smarty2-compatible syntax. Also the file needs a trailing newline.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh this file has crept back in during rebase I think. it shouldnt be there/used
7d51ae3
to
9364b0d
Compare
@@ -116,9 +116,14 @@ | |||
</ul> | |||
|
|||
{foreach from=$allTabs item=tabValue} | |||
{if !empty($tabValue.template)} | |||
{if $tabValue.template} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might this cause an undefined index warning? I think you're right we're not supposed to use empty() in templates but maybe we should use isset() to prevent the e-notice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed to make consistent with https://github.com/civicrm/civicrm-core/pull/31606/files#r1888888349
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but maybe should have changed the other way or changed both to isset?
@@ -29,7 +29,12 @@ | |||
{foreach from=$tabHeader key=tabName item=tabValue} | |||
{if $tabValue.template} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@colemanw I just updated for consistency with here. I added empty
to the bit below to avoid an ENOTICE, so maybe it is good to use for both? Or is isset
preferable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC empty() is not compatible with smarty escaping so it's better to use isset(). I think? Might wanna double check what other templates are doing these days.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://docs.civicrm.org/dev/en/latest/security/outputs/#gotcha-2-smarty-notices
isset = BAD
empty = not great
preferred option is make sure the variable is assigned before the template layer but given the number of places assign('tabHeader', $someVar) happens that looks non trivial and we have a function for that! addExpectedTabHeaderKeys
here we come :)
…t, remove old report related guidance
… for settings tab links
9364b0d
to
b985d82
Compare
This all looks |
This should fix the Smarty unassigned var error: #31636 |
Overview
Currently only Contacts can have CustomGroups with
is_multiple = TRUE
. This adds support for creatingis_multiple
custom groups for Events. These are then displayed as an additional tab in the Manage Events tabset.Before
After
Technical Details
This involves trying to generalise some of the plumbing for AfformTabs - essentially changing hard-coded
contact_id
toentity_id
. In the process I've removedAfformTab.tpl
andAfformBlock.tpl
(the latter change isn't strictly necessary, but feels good step to pave the way for further afform-based functionality for non-Contact entities.Comments